1. Field of the Invention
The invention generally concerns the problem of porting one operating system to another. More specifically, the invention concerns porting operating systems which conform to the POSIX standard to operating systems which conform to the Win32 APL.
2. Description of the Prior Art
When an application programmer writes a program, he or she is writing the program for a machine which is defined by the characteristics of the physical machine that the program is to run on and the operating system which is controlling that physical machine when the physical machine executes the program. Originally, the applications programmer had to know both a programming language specific to the machine he was programming and the operating system that the machine was running. Life became simpler for the applications programmer when programming languages were developed which were machine independent, i.e., their instructions were automatically compiled or interpreted into the proper form for the machine that the program was to be executed on.
There remained the problem of the operating systems. Originally, each computer manufacturer sold its own proprietary operating systems. In the world of commercial data processing, these proprietary operating systems are still dominant; in the world scientific and technical computing, on the other hand, operating systems based on the UNIX operating system LTNIX is a trademark of X/OPEN) became dominant, and eventually, an IEEE and ISO standard for such operating systems emerged. This standard is the so-called POSIX standard (IEEE Std 1003.1b-1993; POSIX is a registered trademark of the IEEE). Operating systems which conform to the POSIX standard exist for hardware of all sizes from personal computers to the largest mainframes (such operating systems are termed herein xe2x80x9cPOSIX operating systemsxe2x80x9d).
The existence of the POSIX standard together with high-level languages such as C or C++ means that the programmer could write a single program which needed only to be recompiled to run on any machine from a personal computer to the largest mainframe, as long as that machine was running a POSIX operating system. As a consequence of this, changing from one manufacturer""s work station to another manufacturer""s work station typically requires little more than a recompilation of the application programs. If, however, the machine the program was to run on had a different operating system, the program had to be extensively rewritten.
At the same time that POSIX was becoming the standard for operating systems n the scientific and technical computer worlds, the personal computer revolution was taking place. Microsoft Corporation become the dominant manufacturer of operating systems for personal computers. By 1993, Microsoft had developed the Win32 Application Program Interface (API) and had announced that all of its future operating systems would conform to the Win32 API. (Win32 is a trademark of Microsoft Corporation; the Win32 API is described in the Win32 Programmer""s Reference, vols. 1-3, Microsoft Press, 1993.) An operating system that implements the Win32 API is termed henceforth a xe2x80x9cWin32 operating systemxe2x80x9d.
Neither the first personal computer systems nor the first Microsoft operating systems were powerful enough to perform the kinds of tasks performed by the machines that ran POSIX operating systems; however, fully-implemented Win32 operating systems are as competent as POSIX operating systems, and the hardware in modem personal computers has become the equal of that found in scientific and technical work stations. At the same time, the number of personal computers is orders of magnitude larger than the number of any other kind of computer. The enormous market for the machines is resulting in a rapid decrease in their cost and in the production of enormous volumes of software for them, and these factors have in turn made the Win32 API a de facto standard of rapidly growing importance.
The emergence of personal computing and the Win32 API has placed the users of programs which are executed on a POSIX operating systems in a difficult position henceforth, xe2x80x9cPOSIX programsxe2x80x9d). On the one hand, the advantages of personal computers are clear: they cost much less than scientific workstations of comparable power and they provide a highly-desirable graphical user interface and numerous useful application programs such as word processors and spreadsheets. On the other hand, POSIX programs will not run on Win32 operating systems without extensive revisions. Thus, the low cost of the personal computers is more than outweighed by the costs of rewriting POSIX software for them and the user of the POSIX programs must choose between his programs and the computing environment offered by personal computers running a Win32 operating system.
One way of avoiding the need to rewrite POSIX programs is to port a POSIX operating system to a Win32 operating system. An operating system is ported to a machine when a version of the operating system is written for the machine. When the version is executed, the machine carries out the functions defined for the operating system. For example, a port of a POSIX operating system to a personal computer is a program which causes the personal computer to carry out the functions defined for POSIX. Of course the xe2x80x9cmachinexe2x80x9d to which the port is made can be defined by an operating system as well as hardware. Thus, a port of a POSIX operating system to a Win32 operating system is code which when executed on a machine that is running the Win32 operating system causes that machine to carry out the functions defined for POSIX.
There are several advantages to porting a POSIX operating system to the Win32 operating system instead of simply porting it to the hardware that the Win32 operating system is running on. First, the POSIX operating system appears to the user of the Win32 operating system simply as another application; thus, the user has available not only the POSIX programs, but also the Win32 programs. Second, POSIX programs running on the ported POSIX operating system can not only access POSIC system calls, but also Win32 system calls.
Given the advantages of porting a POSIX operating system to a Win32 operating system, it is not surprising that at least two attempts have been made to provide such a port. One, NuTCRACKER, is produced by Data Focus Incorporated. NuTCRACKER is a registered trademark of Data Focus Incorporated; information about NuTCRACKER could be found in 1996 at the URL www.datafocus.com. The other, Portage, is produced by Consensys Computers, Inc. Information about Portage could be in 1996 at the URL www.consensys.com. Neither NuTCRACKER nor Portage is a complete port, that is, they reduce the amount of effort needed to adapt a POSIX program to run on a Win32 operating system, but they do not yet have the most important property of a complete port, that is, that all the user of a POSIX program need do to run his POSIX program on the Win32 operating system is to recompile his POSIX program.
Technically, what happens in a port of a POSIX operating system to a Win32 operating system is that each system call in the POSIX operating system is implemented by a function which executes on a Win32 operating system. The code for the function employs the resources provided by the Win32 operating system to provide the semantics specified for the system call in the POSIX operating system. Often, all that is involved in writing a function that implements a POSIX system call in the Win32 operating system is invoking a system call in the Win32 operating system that has the same semantics as the POSIX system call. However, where there are substantial semantic differences between the operating systems, porting is more difficult.
One area in which the differences between the POSIX operating system and the Win32 operating system are particularly large is in the semantics of processes. In a computer system, a process is the entity in the operating system which represents a given execution of a program by the computer system. Typically, each process has its own address space, that is, the program being executed by a given process may read and write data in the given process""s address space, but not in another process""s address space. In order to port a POSIX operating system to the Win32 operating system, it is necessary to overcome the semantic differences between POSIX processes and Win32 processes to that POSIX programs which are in fact being executed by Win32 processes behave exactly as if they were being executed by POSIX processes. It is an object of the present invention to overcome these differences, and thereby to produce a POSIX port to the Win32 operating system which more closely approaches the goal of a complete port than the POSIX to Win32 ports heretofore available.
The foregoing object is attained by implementing a POSIX process by means of a Win32 process in which the primary thread of the Win32 process executes the program specified for the POSIX process and other threads are used to implement POSIX signaling, to maintain the POSIX parent-chld relationships, and to implement the semantics of the POSIX exec function.
The thread which implements POSIX signaling does so by suspending the Win32 process, modifying its state so that the Win32 process will execute the POSIX signal handler at the top of its user stack, and then resuming the Win32 process.
One of the POSIX signals is the SIGCHLD signal, which a POSIX operating system provides to a parent POSIX process when one of its children terminates. This signal is implemented by employing another thread which resumes execution when the child terminates and provides the SIGCHLD signal to the parent. The signaling thread then responds to the signal by executing the handler as described above.
Another aspect of the invention is methods for performing the POSIX fork and exec operations using Win32 processes. In the case of fork, the Win32 process executing fork (the forking process) saves jump state for a later transfer of control, creates a new Win32 process (the forked process) and copies its state, including the jump state, to the forked process. The forked process that performs an operation which transfers control as specified in the jump state.
In the case of exec, the Win32 process performing the exec operation (the xe2x80x9cexecing processxe2x80x9d) replaces itself with a new Win32 process but preservers the parentchild relationships of the POSIX process corresponding to the execing Win32 process are preserved and then terminates itself.